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(54) PROCEDE DE CREATION DE FICHIERS DE CONFIGURATION D'OBJETS INCLUS DANS UN SYSTEME 
INFORMATIQUE. 

(57) L'invention a pour objet la creation d'au moins un fi- 
chier de configuration d'au moins un objet materiel et/ou lo- 
giciel comprenant des parametres, ledit fichier de 
configuration etant ecrit en utilisant un metalangage de des- 
cription dont le format est independant du materiel et/ ou lo- 
giciel a configurer, ce fichier de configuration incluant tout 
ou partie des parametres dudit objet et se reposant sur un 
fichier de description definissant des contraintes a respecter 
sur sa structure et sa syntaxe lors de son ecriture. L'inven- 
tion consiste, avant r ecriture du fichier de configuration, 

- a etendre le fichier de description par au moins un mo- 
dele comprenant au moins un parametre decrit dans le fi- 
chier de description, 

- et a valoriser tout ou partie des parametres de ce mo- 
dele. 



FICHIER DE 
CONFIGURATION 
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Procede de creation de fichiers de configuration d'objets inclus dans un 
systeme informatique. 

DESCRIPTION 

5 

Domaine technique 

La presente invention se rapporte a un procede de creation de fichiers 
de configuration d'objets appartenant a un systeme informatique. 

Le systeme informatique comprend des objets materiels (machines, ...), 
10 et/ou logicieis (applications, ...). Ce systeme est indifferemment un systeme 
distribue ou non, heterogene ou non. 

Les objets comprennent des parametres inclus dans un fichier de 
configuration. L'invention s'applique a tout fichier de configuration ecrit dans un 
langage de balisage extensible, c'est-a-dire un langage qui presente de 

15 I'information encadree par des balises. Le fichier de configuration est ecrit en 
utilisant un metalangage de description dont le format est independant du 
materiel et/ou logiciel a configurer. Un metalangage se defini generalement 
comme etant un langage utilise pour decrire un autre langage. Le langage de 
balisage XML (extensible Markup Langage), connu de I'homme du metier, est 

20 bien adapte a la mise en oeuvre de la presente solution. Rappelons que la 
specification du langage XML est definie par le consortium W3C (World Wide 
Web Consortium). Ce consortium est un Organisme de promotion du «World 
Wide Web», qui met au point des normes et des protocoles ouverts et libres, 
dans un souci d' Interoperability maximale. Le fichier de configuration XML a 

25 une structure declaree dans un fichier de description. Ce fichier de description 
comprend la description des parametres de configuration d'un objet et se 
nomme generalement Definition de Type de Document (DTD). Cette definition 
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s'effectue selon un formalisme particulier egalement defini dans la specification 
XML du consortium W3C. 



L'art anterieur 

5 Par definition, I'ecriture d'un fichier de configuration dans un langage 

XML doit obeir a certaines contraintes syntaxiques. En effet, un document XML 
a une structure logique. II se compose de descriptions, d'elements, de 
commentaires, d'appels de caractere et d' instructions de traitement, qui sont 
indiques dans le document par I'intermediaire d'un balisage explicite. Les 

10 elements sont encadrees par de balises ouvrantes, par exemple <preface>, et 
des balises fermantes, par exemple </preface>. Les elements sont structures et 
decrivent les parametres des objets. Les parametres, comme un attribut d'un 
objet, peuvent etre inclus a I'interieur meme des balises. Par exemple, on peut 
ecrire <LIVRE sujet = k> signifiant que I'attribut sujet de I'element LIVRE a la 

15 vaieur K. 

Dans notre exemple de realisation, Les parametres des objets sont 
definis dans un fichier de configuration ecrit dans un langage XML tel que 
defini precedemment. 

Le probleme principal est que les objets a configurer se comptent en 
20 milliers et que plusieurs de ces objets peuvent se reposer sur un meme fichier 
de description DTD et avoir des valeurs identiques pour tout ou partie de leurs 
parametres. Pour construire le fichier de configuration, I'administrateur du 
systeme de gestion doit alors valoriser les parametres decrit dans le fichier de 
description autant de fois qu'il y a d'objets se reposant sur ce fichier DTD. Plus 
25 precisement, supposons que deux objets B1 et B2 se reposent sur un meme 
fichier de description (DTD). Pour configurer I'objet B1, I'utilisateur doit 
valoriser tous les parametres decrit dans le fichier DTD. Pour configurer I'objet 
B2, I'utilisateur doit a nouveau valoriser tous les parametres decrit dans le 
fichier DTD. En consequence, les parametres de meme vaieur sont ecrit autant 
30 de fois qu'il y a d'objets se reposant sur un meme fichier de description. 
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L'ecriture d'un fichier de configuration presente done des redondances. Le 
langage XML etant un langage de configuration da bas niveau, un utilisateur 
est done contraint d'ecrire dans le fichier de configuration des descriptions de 
parametres repetitives dont la semantique est, dans certains cas, sans rapport 
avec ses besoins, ce qui necessite une culture importante de sa part de 
I'ensemble des syntaxes offertes par le langage XML. De ce fait, le fournisseur 
doit fournir avec le fichier de description une documentation precise. II est clair 
qu'un fichier de configuration impose un cout en temps important en ecriture. 

Un autre probleme, lie au nombre important d'objets a decrire, est que si 
un utilisateur situe sur une machine quelconque du reseau souhaite visualiser 
des ressources du systeme informatique configurees dans le fichier de 
configuration, le systeme de gestion doit alors transmettre le fichier de 
configuration a la machine distante par I'intermediaire du reseau. Lorsque le 
fichier de configuration a un gros volume, le flux de donnees entre le systeme 
de gestion et ('application cliente peut s'averer tres important et conduire a 
saturer le systeme de communication entre les applications clientes et le 
systeme de gestion. 

Enfin, un autre probleme est que la syntaxe definie selon les 
recommandations du consortium W3C doit etre respectee a la lettre tout au 
long de l'ecriture du fichier de configuration. Le risque d'erreur lors de l'ecriture 
d'un fichier de configuration est done permanent pour un administrateur du 
systeme de gestion. 



Sommaire de Pinvention 

Un premier but de la solution est done de simplifier considerablement 
l'ecriture des fichiers de configuration reduisant en consequence a la fois le 
cout en temps d'ecriture de celui-ci et le risque d'erreurs d'ecriture. 

Un deuxieme but vise est de reduire la taille du fichier de configuration. 

A cet effet, la solution a pour objet un procede de creation d'au moins un 
fichier de configuration d'objets materiels et/ou logiciels presents dans un 
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systeme informatique, ledit fichier de configuration etant ecrit en utilisant un 
metalangage de description dont le format est independant du materiel et/ou 
logiciel a configurer, ce fichier de configuration incluant tout ou partie des 
parametres desdits objets et se reposant sur un fichier de description 
definissant des contraintes a respecter sur la structure et la syntaxe lors de 
Fecriture dudit fichier de configuration, caracterise en ce qu'il consiste a 
etendre le fichier de description par au moins un modele comprenant au moins 
un parametre decrit dans le fichier de description, et en ce qu'il consiste a 
valoriser tout ou partie des parametres de ce modele. 

II en resulte egalement un fichier de configuration d'objets materiels 
et/ou logiciels presents dans un systeme informatique, ledit fichier de 
configuration etant ecrit en utilisant un metalangage de description dont le 
format est independant du materiel et/ou logiciel a configurer, ce fichier de 
configuration incluant tout ou partie des parametres desdits objets et se 
reposant sur un fichier de description definissant des contraintes a respecter 
sur la structure et la syntaxe lors de I'ecnture dudit fichier de configuration, 
caracterise en ce que le fichier de description est etendu, en ce que ('extension 
comprend au moins un modele incluant au moins un parametre inclus dans le 
fichier de description, et en ce que une partie des parametres de ce modele 
sont valorises. 

L'invention sera mieux comprise a la lecture de la description qui suit, 
donnee a titre d'exemple et faite en reference aux dessins annexes. 

Description d'un exemple de realisation 

Dans les dessins - 

- la figure 1 est une vue synoptique de ('architecture d'un systeme 
informatique sur lequel peut s'appliquer la solution, 

- la figure 2, est une vue d'un modele conforme a la presente solution. 
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Sur la figure 1 , on a represents un systeme informatique SYS distribue 
illustrant un exemple de realisation prefere de la solution. Dans I'exemple 
illustre, ce systeme SYS inclut un systeme de gestion SG et au moins une 
machine M1. Le systeme de gestion SG comprend au moins un systeme 
5 d'exploitation, au moins une memoire de stockage d'informations et au moins 
un processeur controlant le processus du traitement de I'information. Le terme 
gestion est utilise pour etre conforme a la traduction Afnor (Association 
Francaise de NORmalisation) de « Management ». Un systeme de gestion de 
machines de type « Open Master » (marque deposee par la societe BULL 

io S.A.), connu de I'homme du metier, est particulierement bien adapte pour la 
mise en ceuvre de la solution. Ce systeme de gestion peut etre assimile a un 
ensemble de services qui interagissent entre eux pour donner une 
representation objet du monde reel constitue notamment par les machines du 
systeme informatique. C'est une representation objet qu'un administrateur 

15 manipule (surveillance, action) pour gerer le monde reel. La representation 
objet porte sur des objets virtuels du monde reel et constitue un modele objet. 
En d'autres mots, un objet gere par le systeme de gestion est une vue 
abstraite, definie pour les besoins de gestion, d'une ressource logique ou 
physique du systeme informatique. (disque, processeur, memoire, etc.) et/ou 

20 iogiques (fichiers, processus, semaphores, etc.). 

Le systeme de gestion et les machines qu'il gere constitue une 
architecture Client/Serveur. Dans une telle architecture, un application cliente 
interroge le systeme de gestion pour connaitre I'etat des objets geres par le 
systeme de gestion. Le mode ciient/Serveur a I'avantage de permettre a un 

25 utiiisateur appele client (ou application cliente) situe sur une machine, par 
exemple par I'intermediaire d'un simple micro-ordinateur ou d'une station de 
travail, de confier une partie de sa tache ou de ses operations a effectuer au 
serveur a savoir le systeme de gestion. De cette maniere, le client dispose 
d'une capacite de calcul beaucoup plus importante que celle de son micro- 

30 ordinateur. 
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Le systeme informatique peut etre heterogene. Afin de masquer 
I'heterogeneite du systeme informatique, le systeme de gestion SG et les 
machines gerees par le systeme de gestion comprennent au moins un agent 
respectif associe a un protocole de gestion. Un agent assure, entre autres, une 
5 conversion de protocole. 

Le systeme de gestion est relie a une machine geree par I'intermediaire 
d'un reseau quelconque. Le reseau peut etre de type LAN (Local Area 
Network), WAN (Wide Area Network). Un ensemble de couches logicielles 
s'interpose entre le systeme de gestion SG et le reseau RES et entre le reseau 
10 et chaque machine. Pour des raisons de simplification de la description, cet 
ensemble de couches logicielles n'est pas represents sur la figure 1 . 

Chaque objet gere comprend des pararnetres definis dans un fichier de 
configuration de preference ecrit dans un langage de description a balisage 
comportant une structure et incluant tout ou partie des pararnetres (nom, au 
id moins un attribut, au moins une action, etc.) des objets. Le fichier de 
configuration se base sur un fichier distinct appele fichier de description 
definissant les contraintes sur la structure et les contraintes syntaxiques des 
pararnetres pour I'ecriture dudit fichier de configuration associe a un objet 
d'une machine. De preference, le fichier de configuration est ecrit dans un 
20 langage de type XML, et le fichier de description est un fichier de description 
de type DTD, connus de I'homme du metier. Dans notre exemple de realisation, 
ce fichier de configuration XML et le fichier de description DTD sont inclus 
dans le systeme de gestion SG. 

Dans notre exemple de realisation, le fichier de description DTD est 
25 centralise sur le systeme de gestion de facon a etre utilisable par toutes les 
machines du reseau. De preference, les objets geres peuvent etre represents 
par un arbre, chaque noeud de I'arbre representant un objet gere. Une 
application de visualisation APV incluse sur la machine M1 peut interroger le 
fichier de configuration dans le but de recevoir les pararnetres des objets 
:>o configures et de visualiser ces objets sur cette machine. De preference, pour la 
visualisation des pararnetres de configuration des objets, la machine M1 est 
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munie d'un navigateur standard dit « Internet Explorer », connu de I'homme du 
metier, dans lequel un programme en langage JAVA est execute pour lire le 
fichier de configuration, accedant ainsi a son conienu et a sa structure, et pour 
transmettre les informations lues a (aux) applications de visualisation APV. 

Description de parametre s de configuration d'un nhj ^t • 

Un objet comprend comme parametre au moins un attribut. Par exemple, 
un attribut ID est I'identificateur de I'objet, un autre attribut TYPE designe son 
type, et un autre attribut OWNER. De plus, un objet a des proprietes. Dans 
notre exemple, un objet comprend egalement comme parametres: 

■ le nom de I'objet, 

■ les actions que Ton peut executer sur cet objet incluant Taction ouvrir 
pour I'ouverture du noeud, I'action fermer pour la fermeture du noeud, faction 
developper pour visualiser les noeuds subordonnes a un noeud, 

■ et des proprietes graphiques de ce noeud incluant le type de police 
de caractere, I'adresse de I'icone qui lui est associe, et la couleur de fond 
desiree 

Ainsi, dans ce fichier de description DTD, un element « noeud » est 
associe a un noeud, et des elements lui sont subordonnes et sont associes 
respectivement 

■ au nom de I'objet 

■ aux actions (ouvrir, fermer, developper) que Ton peut executer sur cet 

objet, 

■ et aux proprietes graphiques (police de caractere, icone, couleur de 
fond) de cet objet. 

Des attributs peuvent etre associe a un element. Dans notre exemple de 
realisation, ('element « noeud » comprend trois attributs a savoir : 

■ un attribut ID designant son identificateur 

■ un attribut TYPE designant son type 

■ et un attribut designant son proprietaire 
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Un fichier de description DTD definissant un objet de I'arbre peut etre 
ecrit de la fagon suivante, en respectant le formalisme particulier defini dans la 
specification XML du consortium W3C : 

5 < ELEMENT noeud (noeudNom, noeudActions, 

noeud ProprieteGraphique)> 

< ELEMENT noeudActions (action*)> 

< ELEMENT noeudNom (groupeNom, adresseNom, versionNom)> 

< lATTLIST noeud Id CD ATA #REQUIRED 

io TypeCDATA #REQUIRED 

Owner CDATA #REQUIRED 

> 

< ELEMENT noeud Proprietegraphique (police, icone, couleur)> 

15 Dans ce fichier, CDATA #REQUIRED siginifie que I'attribut en question 

doit etre un bloc de texte contenant des caracteres. De plus, I'ecriture 
« action* » signifie que les actions n'ont pas d'attributs et que la syntaxe de ces 
actions a utiliser lors de I'ecriture du fichier de configuration est du texte. 

L'ecriture < lELEMENT noeudNom (groupeNom, adresseNom, 
20 versionNom)> indique que l'element « noeudNom » comprend trois elements 
(groupeNom, adresseNom, versionNom) qui lui sont subordonne. L'element 
« groupeNom » designe le nom de I'objet, l'element « adresseNom » designe 
I'adresse de I'objet, et l'element « versionNom » designe la version de I'objet. 
Ce fichier de description correspondra dans la suite de la description au 
25 fichier de description initialement cree. 

Notons que le nombre de parametres dans notre exemple de realisation 
est reduit pour des raisons de simplification de la description. En general un 
fichier de description comprend un nombre de parametres plus important. 

Dans I'exemple il lustre, supposons par exemple que trois objets (OBJ1, 
30 OBJ2 et 0BJ3) se reposent sur le meme fichier de description DTD defini plus 
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haut. Le probleme principal est que, pour construire le fichier de configuration, 
I'administrateur du systeme de gestion doit valoriser les parametres decrit dans 
le fichier de description autant de fois qu'il y a d'objets se reposant sur ce 
fichier DTD. L'administrateur doit done completer le fichier de configuration 
5 trois fois. Le cout en temps d'une telle ecriture est done considerable. 

A cet effet, la solution consiste a etendre le fichier de description par au 
moins un modele comprenant au moins un parametre inclus dans le fichier de 
description, et en ce qu'il consiste a valoriser une partie des parametres de ce 
modele d'element. En Lespece, la solution consiste a introduire un modele 
io d'element dont I'ecriture respectent des proprietes definies dans ce qui suit. 

Dans notre exemple de realisation, nous avons a definir un ensemble 
d'objets dont les seuls parametres variant entre eux sont 

- I'element « Norn » correspondant au nom des objets (OBJ1, OBJ2 et 
OBJ3), respectivement (JAZZ, POP, SOL), 

is - et I'attribut « ID » correspondant a I'identificateur des objets (OBJ1, 

OBJ2 et OBJ3), respectivement (123, 142, 162). 

Ces deux parametres seront dits indefinis dans le suite de la 
description. Dans I'exemple de realisation, les objets (OBJ1, OBJ2 et OBJ3) 
ont un nom respectif (JAZZ, POP, SOL) et un identificateur respectif (123, 142, 

20 162). 

Conformement a notre hypothese de depart, les autres parametres ont 
la meme valeur pour chaque objet (OBJ1, OBJ2 et OBJ3). lis seront dits 
definis. Ainsi, 

■ la valeur de I'element correspondant aux actions que Ton peut 
executer est la meme pour chaque objet (OBJ1 , 0BJ2 et OBJ3), 

■ la valeur de I'element correspondant aux proprietes graphiques est la 
meme pour chaque objet (OBJ1, OBJ2 et OBJ3) , 

et la valeur des attributs 



25 
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. tvpe designan, >e ,ype du ooje, es, le memo pour chapue oo,e< 
'^^TolTL^ son pro P rie,a,re es, ,e nreme poor cnapue o.e, 

(OBJ1.0BJ2* aCommande «developper».Der,eme, 
commande « fermer », et ACTS pour _ nraDhiaU es de chaque 

la valeur de I'element correspondent aux propnetes graph.ques 

OBJ1 , OB. - OB J3) est pour , po.ce de caracte, = 
, . Pt PROS pour la couleur de fond. Enfin, les attnbuts TYPE et OWN 
,,cone, et PROS pour respec tivement les valeurs 

prennent pour chaque objet (OBJ1 , OBJ2 et 
« snmp » et « operateur ». 

Le s deu* .tapes prinopa.es du precede conforme , la solution son, 

respectivement 

. r ecn, U r e du tichier de description DTD e, de ,'ex,ens,on assocae a oe 
flch ier constitue par ao mens un modele d'element (etape 1), 

. e, recri.ure du flchier de configuration resultant de ia valorisation des 
M parametres indefinis du modele d'elemen, (e.ape 2). 

S^e^MSSm^MSJ lD f*hier *> desc riBflon: 

La premiere etape doi, realisee en respectant oertaines propr.etes. Us 
T Is olts don, ,a vaieur est .nvariante etan. identifies, la 

descnpflon DTD cree. Le mod„e deleraen, se d,stin 3 ue des autres element 
de descnpflon en ce sens gu'i, compcrte au moins un parame.re avec 



une valeur. 
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Premierement, le modele comprend, en respectant le formalisme 
d'ecriture d'un fichier de description DTD defini dans la specification XML du 
consortium W3C, 

- une entete MODELE avec un nom specifique « tnoeud » 

- et une reference a un element « noeud » defini du fichier de 
description DTD cree initialement. 

Le modele MODELE peut etre ecrit de la fagon suivante : 

< IMODELE Inoeud ELEMENT =noeud > 

signifiant que le modele MODELE a un nom specifique « tnoeud » et 
qu'il se base sur la description de I'element « noeud » defini au prealable dans 
le fichier de desciption (DTD). 

Deuxiemement, dans ce modele, I'ecriture des elements indefinis est 
particuliere. De facon a distinguer un element defini d'un element indefini dans 
le modele d'element, les elements a definir sont reperes dans ce modele par 
I'intermediaire d'une balise specifique dont I'entete est par exemple 
< ! DEFINIR.. .>. De plus, les elements a definir sont identifies par un nom 
« tnoeudNom » et une reference a un element noeudNom du fichier de 
description initial precisant sur quel element du fichier de description 
prealablement defini se base le modele d'element « tnoeudNom ». Dans notre 
exemple, un element a definir peut s'ecrire de la facon suivante : 

< IDEFINIR tnoeudNom. ..ELEMENT noeudNom >. 

A la difference des elements indefinis, les elements definis du modele 
d'element sont ecrits de la meme fagon que pour I'ecriture d'un fichier de 
configuration XML. 

Troisiemement, I'ecriture des attributs indefinis respecte des proprietes 
Dans ce modele, les attributs a definir et definis, ia solution consiste a 
introduire deux mots cles DEFINIR et DEFINI indiquant qu'un parametre 
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attribut est a definir (DEFINIR) ou est defini (DEFINI). Dans notre exemple, 
I'attribut ID est a definir iors de I'ecriture du fichier de configuration, tandis que 
les attributs TYPE et OWNER sont definis et prennent respectivement les 
valeurs « snmp » et « operateur ». Dans notre exemple, la liste d'attributs est 
5 relative au modele d'element MODELE « tnoeud » et peut s'ecrire de la facon 
suivante : 

< ! ATTLIST tnoeud 

ID DEFINIR 

TYPE DEFINI « snmp » 
io OWNER DEFINI « operateur » 

> 

En definitive, le fichier de description DTD qui decoule d'une telle 
configuration peut s'ecrire de ia facon suivante : 

< IMODELE tnoeud ELEMENT=noeud 

15 < IDEFINIR tnoeudNom ELEMENT=noeudNom> 

< noeudActions > 

<action nom=ouvrir> ACT1 </action> 
<action nom=fermer>ACT2</action> 
<action nom=developper>ACT3</action> 
20 </ noeudActions > 

< noeudProprietesgraphiques > 

<police de caracteres PRO 1 ... /> 
<lc6ne>PR02</lcone> 
< couleur de fond PR03/> 
25 < / Proprietesgraphiques > 

> 

< ! ATTLIST tnoeud 

ID DEFINIR 

TYPE DEFINI « snmp » 
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OWNER DEFINI « operateur>> 

>. 

Ce fichier constitue un facteur commun FC pour l'ecriture du fichier de 
configuration et decrit les parametres (element et/ou attribut) a definir. 

Ecriture du fichier de configuration 

La figure 2 est une vue du fichier de configuration qui resulte de 
I'utilisation du modele d'element. 

L'ecriture du fichier de configuration correspond a la deuxieme etape. 
Cette operation consiste a utiliser le modele d'element MODELE defini dans le 
fichier de description DTD et a valoriser les elements et attributs indefinis. Lors 
de l'ecriture du fichier de configuration, la solution consiste a utiliser la partie 
comprenant les parametres valorises comme facteur commun, et en ce que 
l'ecriture se limite a la valorisation des parametres ne comportant pas de 
valeur. 

En I'espece, trois objets (OBJ1, OBJ2 et OBJ3) ayant pour nom 
respectif (JAZZ, POP, SOL) et un identificateur respectif (123, 142, 162) sont a 
configurer et I'ecriture du fichier de configuration pour ces trois objets se limite 
a ecrire les trois blocs suivants (B1 , B2 et B3) : 

(Bl) 

<tnoeud ' ld= «123»> 
< tnoeudNom > 
<noeudNom> 

<groupeNom> JAZZ </groupeNom> 
<adresseNom> dbO </ adresseNom > 
<versionNorn> 8.0 <versionNom> 
</noeudNom> 
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</ tnoeudNom > 
</tnoeud> 

(B2) 

5 < tnoeud Id- «142>» 

< tnoeudNom > 

<noeudNom> 

<groupeNom> POP </groupeNom> 
<adresseNom> dbl </ adresseNom > 
io <versionNom> 8.1 <versionNom> 

</noeudNom> 
</ tnoeudNom > 
<!tnoeud> 

is (B3) 

< tnoeud ld= «162»> 

< tnoeudNom > 

<noeudNom> 

<groupeNom> SOL </groupeNom> 
w <adresseNom> db2 </ adresseNom > 

<versionNom> 8.2 <versionNom> 
</noeudNom> 
</ tnoeudNom > 
<ltnoeud> 

5 Le nombre d' invocation du modele d'element correspond au nombre 

d'objets se reposant sur ce modele MODELE. Ces trois blocs ont pour meme 
facteur commun celui cree dans le fichier de description. 

Selon une variante, un modele d'element peut contenir d'autres modeles 
d'elements. Ainsi, dans un fichier de configuration, on peut utiliser a I'interieur 
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d'une reference de modele d'element (par exemple « tnoeud ») une autre 
reference de modele d'elements. En effet, supposons qu'il existe dans le fichier 
de description DTD un modele d'element « tOracleNoeudNom » dont les 
elements definis sont 

■ I'element nomme groupeNom 

■ et I'element versionNom 

et dont I'element indefini est adresseNom. L'ecriture de ce modele d'element 
peut etre le suivant : 

< IMODELE tOracle8NodeName ELEMENT=noeudNom 

<groupeNom> Oracle </groupeNom> 

< IDEFINIR tOracleDb ELEMENT-adresseNom> 

<versionNom> 8.0 <versionNom> 

> 

De cette facon, lors de l'ecriture du fichier de configuration, on peut 
utiliser le modele « tOracleNoeudNom » pour definir I'element noeudNom. Le 
fichier de configuration s'ecrit alors de la facon suivante : 

< tnoeud ld=«123»> 
< tnoeudNom> 

< tOrocle8NoeudNom> 

< tOracleDb> 

<adresseNom> dbO </adresseNom> 
</ tOracleDb> 
</ tOracle8NoeudNom> 
</ tnoeudNom > 
</fnoeud> 

D'une maniere generale, la solution a pour objet un procede de creation, 
dans un systeme informatique, d'au moins un fichier de configuration d'au 
moins un objet materiel et/ou logiciel comprenant des parametres, ledit fichier 
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de configuration etant ecrit en utilisant un metalangage de description dont le 
format est independant du materiel et/ou logiciel a configurer, ce fichier de 
configuration inciuant tout ou partie des parametres dudit objet et se reposant 
sur un fichier de description definissant des contraintes a respecter sur sa 
5 structure et sa syntaxe lors de son ecriture, caracterise en ce qu'il consiste, 
avant I'ecriture du fichier de configuration, a etendre le fichier de description 
par au moins un modele comprenant au moins un parametre decrit dans le 
fichier de description, et a valoriser tout ou partie des parametres de ce 
modele. 

iu Ensuite, lors de I'ecriture du fichier de configuration, la solution consiste 

a utiliser la partie du modele comprenant les parametres valorises comme 
facteur commun, et en ce que I'ecriture du fichier de configuration se limite a la 
valorisation des parametres ne comportant pas de valeur. 

Lors de la creation du modele, on a vu que la solution peut consister 
15 tout d'abord a regrouper les objets se reposant sur le meme fichier de 
description, ensuite a identifier les parametres dont la valeur est identique 
entre tous ces objets, et enfin e a valoriser ces parametres pour constituer un 
facteur commun dans ce modele. 

La solution consiste par exemple, lors de I'ecriture du fichier de 
20 configuration, si au moins deux objets se reposent sur le meme modele, a 
utiliser le facteur commun et a valoriser uniquement le restant des parametres 
de ce modele autant de fois qu'il y a d'objets se reposant sur ce modele 

d'element. 

Le langage utilise est extensible. Dans notre exemple, on a vu que la 
25 solution consiste a donner un nom pour identifier le modele dans le fichier de 
description, et en ce qu'il consiste a inclure dans le modele une reference du 
fichier de description, cette reference definissant les contraintes a respecter 
sur la structure et la syntaxe de ce modele. On a vu egalement que dans notre 
exemple, la solution consiste a introduire dans un modele deux mots des 
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DEFiNIR et DEFINI indiquant qu'un parametre est a definir (DEFINIR) ou est 
defini (DEFINI) dans ce modele. 

De preference, le langage du fichier de configuration est le langage 
XML, la solution consistant a prendre comme parametre un element et/ou un 
attribut d'un objet. Selon cette variante, la solution consiste a etendre le fichier 
de description par au moins un modele d'element comprenant au moins un 
parametre (element et/ou attribut) decrit dans le fichier de description, et a 
valoriser tout ou partie des parametres de ce modele d'element. De meme, la 
solution consiste a donner un nom pour identifier le modele d'element dans le 
fichier de description, et en ce qu'il consiste a inclure dans le modele une 
reference a un element du fichier de description, cette reference definissant les 
contraintes a respecter sur la structure et la syntaxe de ce modele. 

Enfin, on a vu que, sur requete d'une application utilisant le fichier de 
configuration, la solution peut consister a transmettre le facteur commun et les 
blocs resultant de la valorisation des elements indefinis. 

Enfin, il en resulte un fichier de configuration d'au moins un objet 
materiel et/ou logiciel comprenant des parametres, ledit fichier de configuration 
etant ecrit en utilisant un metalangage de description dont le format est 
independant du materiel et/ou logiciel a configurer, ce fichier de configuration 
incluant tout ou partie des parametres dudit objet et se reposant sur un fichier 
de description definissant des contraintes a respecter sur sa structure et sa 
syntaxe lors de son ecriture, caracterise en ce que le fichier de description est 
etendu, et en ce que I'extension comprend au moins un modele. 

En conclusion, la solution offre de nombreux avantages. Un premier 
avantage est la simplification considerable de I'ecriture d'un fichier de 
configuration. En effet, les parametres definis etant valorises dans le modele 
d'element, I'ecriture du fichier de configuration se limite a la valorisation des 
parametres indefinis. En consequence, I'administrateur evite ainsi la repetition 
de parametres identiques entre objets. Le cout en temps d'ecriture et le risque 
d'erreurs d'ecriture lors de I'ecriture du fichier de configuration est largement 
reduit. De plus, introduction d'un facteur commun dans le modele reduit 
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REVENDICATIONS 

1- Procede de creation, dans un systeme informatique, d'au moins un 
fichier de configuration d'au moins un objet materiel et/ou logiciel comprenant 
5 des parametres, ledit fichier de configuration etant stocke dans une memoire 
de stockage d'information et etant ecrit en utilisant un metalangage de 
description dont le format est independant du materiel et/ou logiciel a 
configurer, ce fichier de configuration incluant tout ou partie des parametres 
dudit objet et se reposant sur un fichier de description definissant des 
10 contraintes a respecter sur sa structure et sa syntaxe lors de son ecriture, 
caracterise en ce qu'il consiste, avant I'ecriture du fichier de configuration, 

- a etendre le fichier de description par au moins un modele comprenant 
au moins un parametre decrit dans le fichier de description, 

- et a valoriser tout ou partie des parametres de ce modele. 

15 2- Procede selon la revendication 1, caracterise en ce qu'il consiste, lors 

de I'ecriture du fichier de configuration, a utiliser la partie du modele 
comprenant les parametres valorises comme facteur commun, et en ce que 
I'ecriture du fichier de configuration se limite a la valorisation des parametres ne 
comportant pas de valeur. 

20 3- Procede selon la revendication 1 ou 2, caracterise en ce qu'il 

consiste, lors de la creation du modele, a regrouper les objets se reposant sur 
le meme fichier de description et ensuite a identifier les parametres dont la 
valeur est identique entre tous ces objets, et en ce qu'il consiste a valoriser ces 
parametres pour constituer un facteur commun dans ce modele. 

25 4- Procede selon I'une des revendications 1 a 3, caracterise en ce qu'il 

consiste, lors de I'ecriture du fichier de configuration, si au moins deux objets 
se reposent sur le meme modele, a utiliser le facteur commun et a valoriser 
uniquement le restant des parametres de ce modele autant de fois qu'il y a 
d'objets se reposant sur ce modele d'element. 
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5- Procede selon I'une des revendications 1 a 4, caracterise en ce que 
le langage est extensible et en ce qu'il consiste a donner un nom pour identifier 
le modele dans le fichier de description, et en ce qu'il consiste a inclure dans le 
modele une reference du fichier de description, cette reference definissant les 

5 contraintes a respecter sur la structure et la syntaxe de ce modele. 

6- Procede selon I'une des revendications 1 a 5, caracterise en ce que 
le langage est extensible et en ce qu'il consiste a introduire dans un modele 
deux mots cles DEFINIR et DEFINI indiquant qu'un parametre est a definir 
(DEFINIR) ou est defini (DEFINI) dans ce modele. 

io 7- Procede selon I'une des revendications 1 a 6, caracterise en ce que 

le langage est le langage XML, et en ce qu'il consiste a prendre comme 
parametre un element et/ou un attribut d'un objet. 

8- Procede selon la revendication 7, caracterise en ce qu'il consiste a 
etendre le fichier de description par au moins un modele d'element comprenant 

15 au moins un parametre (element et/ou attribut) decrit dans le fichier de 
description, et a valoriser tout ou partie des parametres de ce modele 

9- Procede selon la revendication 7 ou 8, caracterise en ce qu'il consiste 
a donner un nom pour identifier le modele d'element dans le fichier de 
description, et en ce qu'il consiste a inclure dans le modele une reference a un 

20 element du fichier de description, cette reference definissant les contraintes a 
respecter sur la structure et la syntaxe de ce modele. 

10- Procede selon I'une des revendication 7 a 9, caracterise en ce qu'il 
consiste a inclure dans un modele d'element au moins un modele d'element. 

11- Procede selon I'une des revendications 7 a 10, caracterise en ce 
25 qu'il consiste, sur requete d'une application utilisant le fichier de configuration, 

a transmettre le facteur commun et les blocs resultant de la valorisation des 
elements indefinis. 
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